Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / answers / comp / osi-protocols < prev next >

Wrap

Text File | 1994-01-20 | 51.3 KB | 1,105 lines

Path: bloom-beacon.mit.edu!think.com!cass.ma02.bull.com!spool.mu.edu!howland.reston.ans.net!pipex!uunet!Germany.EU.net!netmbx.de!zib-berlin.de!news.th-darmstadt.de!fauern!rz.unibw-muenchen.de!rrze.uni-erlangen.de!not-for-mail From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn) Newsgroups: comp.protocols.iso,comp.answers,news.answers Subject: comp.protocols.iso FAQ Supersedes: <osi-faq_755896647@cd4680fs.rrze.uni-erlangen.de> Followup-To: comp.protocols.iso Date: Thu, 13 Jan 1994 17:24:51 +0100 Organization: Regionales Rechenzentrum Erlangen, Germany Approved: news-answers-request@MIT.Edu Expires: 26 Feb 1994 16:24:45 GMT Message-ID: <osi-faq_758478285@cd4680fs.rrze.uni-erlangen.de> Reply-To: mskuhn@cip.informatik.uni-erlangen.de NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de Lines: 1085 Summary: Introductory information about OSI, a family of internationally standardized computer communication protocols and services. Keywords: OSI, computer networks, standards, data communication, open systems Xref: bloom-beacon.mit.edu comp.protocols.iso:1969 comp.answers:3370 news.answers:14030 Archive-name: osi-protocols Last-modified: $Date: 93/12/14 20:15:56 $ Version: $Revision: 1.9 $ Frequently Asked Questions about OSI with Answers ------------------------------------------------- This text is a monthly posting to the USENET group comp.protocols.iso. Its purpose is to give answers to some of the questions appearing most often in this group, to offer a minimal starting point in the learning curve of OSI beginners and to collect interesting information that appeared in USENET discussions. Another FAQ (Archive-Name: standards-faq) which is posted to comp.protocols.iso and comp.std.misc contains information about the international standardization organizations (ISO, CCITT, ...), where their documents are available, what Internet recources provide information about standards etc. This FAQ is crossposted to news.answers and won't expire there on well-managed news systems until the next version has been posted. As a consequence of being crossposted to news.answers, this text will also be automatically archived on many FAQ servers all over the world (e.g., look with anonymous ftp at rtfm.mit.edu in /pub/usenet/news.answers). You'll also find there many other answers to frequently asked questions. The author of this FAQ has lost much of his enthusiasm for OSI since the first version has been posted and won't spend too much time in maintaining it. If you have much more energy left for this subject and are interested in continuing with the FAQ, just contact me! I'll concentrate on this text's brother, the Standards FAQ, which has received much more interest and contributions. I hope you enjoy it ... Markus Contents -------- What is OSI? What is the OSI reference model? What is ASN.1? What OSI standards are there? How are OSI and TCP/IP related? Which is better: TCP/IP or OSI? OSI criticism Which free OSI implementations are available? ! New and planned OSI standards Books and Journals A '+' in the first column marks a topic that has been added since this FAQ has been posted the last time and a '!' marks a change. Trivial typographic changes are not marked. What is OSI? ------------ "the first successful worldwide attempt to develop a set of comprehensive standards for computer communications" (Uyless Black) OSI is an abbreviation for Open Systems Interconnection. In the early 80's, people in several standardization committees all over the world felt that the time had come to develop a set of non-proprietary standard protocols. They hope that one day these protocols will replace most of the vendor-dependent specifications and that this will make the way free for easy and flexible world-wide computer communication. It took nearly a decade before the first results were produced: a reference model and a set of layer standards from physical cable definitions up to distributed databases and information systems, together with management and security tools. The process of standardization hasn't been finished yet and probably won't be in the next decade, but we already have a powerful set of protocols for the most important applications. These specifications have been published as ISO standards and CCITT recommendations. What is the OSI reference model? -------------------------------- A good international standard should be flexible and extensible. In order to achieve this goal, it seems to be a good idea to separate a complex structure like a computer protocol in several modules. Each module should be of manageable size and, if different techniques are available for a certain aspect of a protocol, then the separation into modules makes it quite easy to change this part of the whole system (e.g. the cable specification or the encoding of data) without touching the rest of the specification. The OSI Reference Model (RM) defined in ISO 7498 divides the communication process between two application programs into 7 intermediate layers. Each layer provides a certain kind of service to the next higher layer. This service is provided by communicating with the peer entity in same layer of the remote host using the service provided by the next lower layer. Some of the layer entities may be implemented in physical devices, some may be part of the operating system and some may be included in application programs. Most layers provide their service by forwarding protocol data units to the next layer together with an added or removed header or by performing other functions and state changes. The OSI Reference Model only defines the abstract notion of layers and does not specify whether the boundaries between the layers have to be visible and documented in implementations. There are other standards that define application program interfaces (APIs) between the operating system and the application and these APIs often correspond to a layer boundary in the OSI Reference Model. The classic standard diagram that is normally used to describe the OSI RM looks like this: End System End System +-------+ +-------+ | 7 | | 7 | Application Layer +-------+ +-------+ | 6 | | 6 | Presentation Layer +-------+ +-------+ | 5 | Intermediate | 5 | Session Layer +-------+ System +-------+ | 4 | | 4 | Transport Layer +-------+ +-----------+ +-------+ | 3 | | 3 | | 3 | Network Layer +-------+ +-----+-----+ +-------+ | 2 | | 2 | 2 | | 2 | Data Link Layer +-------+ +-----+-----+ +-------+ | 1 | | 1 | 1 | | 1 | Physical Layer +-------+ +-----+-----+ +-------+ | | | | +------------+ +----...-----+ The PHYSICAL LAYER provides the service of transferring bits from one end of the physical medium to the other. This includes the specification of the medium (wire, coax cable, fiber optics, radio signals, laser signals, microwave signals, seismic waves, ... :-) as well as the connectors, the modulation techniques, environmental limits etc. The DATA LINK LAYER uses the bit-transfer ability of the physical layer to provide a secured link between two hosts. This includes functions like error detection and correction, separating data blocks, controlling media access, etc. In a network, not every computer has to be connected to each other directly. Hosts should be able to forward data packets according to an address field that has been attached to the packet. The NETWORK LAYER provides the service of routing and delivering a packet to any host in the network. In intermediate systems, where there's no application program involved in the communication, the packets are only processed by the lower three layers. Each layer (especially 2 and 3) can operate in two different modes. In the CONNECTION-ORIENTED (CO) mode, the communication goes through several stages similar to a telephone call: (1) dial, (2) wait until the connection has been established, (3) communicate, (4) close the connection, (5) wait until close of the connection has been confirmed. The connection-oriented mode guarantees that no packets are lost and that all packets arrive in the same order in which they have been sent. In contrast, in the CONNECTIONLESS (CL) mode only a datagram service is provided, similar to the postal letter service. No one guarantees that the letters arrive in the same order in which they have been sent, and every intermediate system is allowed to discard a packet if there are insufficient resources available to deal with it (e.g. buffers are full). In CL-mode systems, higher layers have to deal with resequencing, retransmission of lost packets, etc. where a reliable data stream is required. There is endless debate about whether the CONS (connection-oriented network service) or the CLNS should be provided by the network layer and now both alternatives have been defined in OSI standard protocols. As most applications want to exchange several packets in sequence, they need a CO-mode service. The TRANSPORT LAYER has been introduced in order to hide the differences between several network concepts (CO vs. CL and other things like maximum packet size and quality of service) from the connection-oriented transport service (COTS) user. In the case of a CO network, the COTS is quite simple to provide, but over a CL network, complete error correction and flow control has to be provided in the transport layer. The main advantage of the CLNS is higher efficiency because fewer CPU cycles for complex flow control algorithms are needed in intermediate systems (routers). If no connection-oriented transport service is needed, then the response time may be significantly shorter over a CLNS. CONS, on the other hand, makes accounting easier for network providers, as only correctly delivered packets are counted. The headers of the connection-oriented network protocol packets may be much shorter, as the full address is not required in each packet, which might be relevant on slow lines. In addition, many existing nets are CO, e.g. X.25 nets, the telephone net and ISDN. The SESSION LAYER offers a mechanism to include synchronization points in the stream of exchanged packets and to go back to one of the previous sync points. This might be useful if large files are transferred and it is possible to recover after a breakdown without having to retransfer the whole file. The session layer only provides the means to negotiate a recovery. The recovery has to be done by the application and not by the software that implements the session layer. This is the reason why many experts consider the session layer as one of the darker corners of the OSI model, especially as this part of the standard is quite complex and difficult to understand. Perhaps it would have been a better choice to include the session layer functionality somewhere in the application layer. Don't worry if you don't understand the exact ideas behind the design of the session layer, you are not alone. There are even obscure relations with CCITT T.62, although only very few people seem to understand why compatibility with an old Teletex protocol was necessary in the session layer design ... The PRESENTATION LAYER provides for negotiation of the form of representation (syntax) of the data that will be transferred. This makes sense if several optional ASN.1 encodings or other syntaxes (e.g. the X Window System protocol) are possible. Finally, the APPLICATION LAYER provides an application-specific service. This is not the application itself, but the application layer is directly used by an application program. For instance, an electronic mail user interface program might use the X.400 application layer in order to send a message to another host. Here the application layer will deal with things like address resolution, routing decisions, transferring and converting (even very huge) messages, etc. Other application layer standards offer services like accessing remote file systems, controlling video terminals and transaction systems, etc. In addition to the 7 layers, the OSI Reference Model defines a management and a security architecture that includes all 7 layers. The seven layer model seems to have been first mentioned in the literature in "A Tutorial on Protocols" by Louis Pouzin and Hubert Zimmerman in Proceedings of the IEEE, Volume 66, Number 11 (November 1978), pages 1346-1370. What is ASN.1? -------------- Most protocols are defined as sets of protocol data units (PDUs) that might be exchanged between two hosts. A PDU is a sequence of bytes that one host uses to tell the other one something according to the rules of the protocol. Quite early in the OSI project, it was recognized that a formal way of defining the syntax of PDUs was needed, i.e. something like the well-known context-free Backus-Naur grammars (BNF) are used to define the syntax of programming languages. ASN.1 (abstract syntax notation number 1) plays the same role in defining OSI protocols that BNF plays in the definition of a programming language: it gives a precise and parseable specification how PDUs are structured and which structures are allowed, but it says nothing about the meaning of a PDU. This is still defined in English language in the OSI standards. ASN.1 specifies only the 'abstract syntax' of a PDU. This means that it only says that, for example, a PDU consists of 2 integer numbers (of arbitrary size), one optional UTC time value and one ISO 10646 string or, alternatively, one ASCII string. ASN.1 doesn't define the 'transfer syntax', the way in which the values in the abstract syntax (e.g. {2, 42, 1992-10-6 10:09:34, "Hey!"}) are encoded in the sending or receiving computers, or on the transmission path between them. Several different transfer syntaxes have been defined. The most widely used one is BER (basic encoding rules). Other transfer syntaxes are simplified BER subsets or provide a one-to-one mapping between abstract value and the bit string for cryptographic applications or are optimized with regard to CPU time or PDU length. An example: NonsenseProtocol ::= CHOICE { testPDU [0] TestPDU, -- Our example getFile [1] GetFile -- another possible PDU } TestPDU ::= SEQUENCE { aNumber INTEGER, anotherNumber INTEGER, today UTCTime OPTIONAL, theText CHOICE { multilingualText ISO10646String, standardText VisibleString } } The BER encoding consists of tag-length-value triples for both composed types (CHOICE, SEQUENCE, SEQUENCE OF, SET, SET OF, tags, ...) and primitive types (integers, strings, ...). The tag identifies the type of the value (e.g. 0 for testPDU and 1 for getFile) and the length defines the end of the TLV triple. This allows an implementation to jump efficiently over (perhaps even unknown) values and makes ASN.1 defined protocols very extensible. As an example the encoding of the value {2, 42, 1992-10-6 10:09:34, "Hey!"} of type NonsenseProtocol: a0 80 ----------------------- Length encoding: indefinite. +--------------------------- Explicit tag: [0] means that we took the testPDU alternative of the choice. 30 80 ----------------------- again indefinite length form, as we don't | know how long the SEQUENCE will finally be. | Consequently, the end of the SEQUENCE will | have to be marked by a 00 00 component. +--------------------------- This is a composite type SEQUENCE. 02 01 02 -------------------- The value 2. | +------------------------ Length of the value: 1 byte. +--------------------------- This is an INTEGER value. 02 01 2a -------------------- The value 42. | +------------------------ Length of the value: 1 byte. +--------------------------- This is another INTEGER value. 17 0d 39 32 31 30 30 36 31 30 30 39 33 34 5a | | -------------------------------------- | | +------ The encoded date and time. | +------------------------ Length: 13 bytes. +--------------------------- Type: UTCTime. 1a 04 48 65 79 21 | | ----------- | | +----------------- The value: 'Hey!' coded in ASCII. | +------------------------ This is 4 bytes long. +--------------------------- We used the VisibleString alternative of CHOICE. 00 00 ----------------------- This is the end of the indefinite length SEQUENCE. 00 00 ----------------------- This is the end of the explicitly tagged CHOICE alternative TestPDU. Another very important ASN.1 concept and data type are object identifiers. These are lists of integers that uniquely identify any object in a protocol, e.g. a X.400 body part, a DFR document type, a X.500 attribute type, a public key algorithm, a protocol version, etc. If one object identifier is yours, then only you are allowed to append further numbers to your OID and create new object identifiers that only belong to you. You may give some of your newly created object identifiers to other people, and, then, they also have the right of creating their own new subtrees in the OID space. The highest levels in this tree belong to ISO and CCITT, and they have already reserved OIDs for many organizations. This allows you, for instance, to define your own X.400 high-end cyberspace body part, and it won't collide with someone else's self-defined body part if a prefix of the OID belongs to you. As many options in OSI protocols are identified by OIDs, it is very easy for implementors to extend the protocols without getting in conflict with older implementations which will know that they don't know this new OID. Many protocols exchange sets of OIDs that identify their implemented subsets and extensions after the connection has been established and automatically determine the biggest common subset of all optional protocol features that both may use. Today ASN.1/BER are also used in many non-OSI protocols and file formats, and there are a number of tools (ASN.1 compilers) available that help to create parsers automatically from ASN.1 specifications. [See also the section about new standards.] What OSI standards are there? ----------------------------- As two organizations (ISO and ITU) have been involved in the OSI standardization process, many of the specifications have been published as both ISO standards and CCITT recommendations (CCITT recommendations will in the future be called ITU-T recommendations). In these cases, both versions are "technically aligned" or one version is a subset of the other one. The OSI Reference Model, as defined in ISO 7498-1 and CCITT recommendation X.200, describes the details of the seven-layer model. The three other parts of ISO 7498 describe the Security Architecture, Naming and Addressing and the Management Framework. Formal protocol description methods are defined in ISO 8807 (LOTOS, Language Of Temporal Ordering and Specification), ISO 9074 (ESTELLE) and ISO 9496 (CHILL). ISO 9646 standardizes methods for conformance testing e.g. the Tree and Tabular Combined Notation (TTCN) for test suites. ISO TR 10167 (Application guidelines for ESTELLE, LOTOS and SDL) includes a number of examples of systems, showing how each of them can be specified using these three standards. International registration procedures for things like OSI document types, object identifiers, virtual terminal profiles and control objects and application process titles are described in ISO 9834 and X.660. Registration means that a world-wide unique identifier will be reserved for your extension to an OSI protocol, which guarantees that extensions developed by different people won't collide with each other and possible future ISO extensions. ISO 8824 and X.208 standardize ASN.1. ISO 8825 and X.209 standardize the Encoding Rules (BER and soon others) for it. [See also the section about new standards.] The details of the Security Framework are defined in ISO 10181, and ISO 10745 describes the Upper Layers Security Model. Several security techniques are standardized in ISO 9796 (Digital Signature Scheme Giving Message Recovery) and ISO 9798 (Entity Authentication Mechanisms, Symmetric Techniques and Public Key Algorithms). You may register your own cryptographic algorithms as defined in ISO 9979. Many OSI standards have been divided in two documents, the service definition and the protocol specification, in order to separate the description of the functionality from the description of the protocol realization. Layer seven has been further subdivided into several modules (service elements), as some of them may be useful for more than one application. This Application Layer Structure is defined in ISO 9545 and CCITT X.207. The Association Control Service Element (ACSE) (ISO 8649|X.217 service definition and ISO 8650|X.227 protocol definition) manages the establishment of a connection between two remote applications. CCR (Commitment, Concurrency and Recovery) is a service element that provides services needed for keeping distributed databases consistent (ISO 9804/9805|X.861/871). ISO 9066 and CCITT X.218/228 define the Reliable Transfer Service Element (RTSE) that transfers huge messages safely from one node to the next one with recovery, etc. (e.g. used by e-mail). The Remote Operations Service Element (ROSE) allows a client to execute operations at a server process and to receive the results or error indications. Now, it's time to come to the most interesting part of the whole OSI story, the application services and protocols: ISO 9595 and CCITT X.710 define the Common Management Information Service (CMIS) and ISO 9596|X.711 the Common Management Information Protocol (CMIP) that may be used for controlling all parts of a computer network, e.g. routers, queues, environmental sensors, accounts, security logs, installed software versions, clocks, etc. ISO 10164 describes these various aspects of System Management, and ISO 10165 standardizes the Management Information Model used for controlling all these devices. FTAM (File Transfer, Access and Management) is a protocol defined in ISO 8571 that has been designed for both simple file transfers a la kermit and DoD ftp and for directly accessing remote file systems like NFS, etc. The Virtual Terminal (VT) service and protocol specified in ISO 9040 and ISO 9041 allow a host application to control a terminal with screen and keyboard and similar devices like printers. In addition, not only application-terminal, but also the less common application-application and terminal-terminal communication is supported. Today, only the Basic Class VT, which covers character-oriented terminals has been specified. This service is comparable to DoD Telnet and the old CCITT X.3/X.28/X.29 PAD protocol, but much more powerful. It also includes control of cursor movement, colors, character sets and attributes, access rights, synchronization, multiple pages, facility negotation, etc. This means that the huge number of classic terminal type definitions (e.g. in UNIX termcap or terminfo) are unnecessary at each host in the net, as the VT protocol includes the corresponding commands for one abstract virtual terminal that only have to be converted by the local implementation to the actual terminal control sequences. Consequently, the use of VT means not every host needs to know every type of terminal. As with most ISO standards that require general consensus amongst participating members, the OSI VT has many optional capabilities, two modes of operation and an almost infinite number of implementation- specific options. Profiles may help in reducing the optionality present (e.g., there exists a Telnet profile for VT). But it is doubtful that the OSI VT can completely put an end to the 'm x n' terminal incompatibility problem that exists in a heterogeneous computer network. ISO 8831 and ISO 8832 define the Job Transfer and Manipulation (JTM) protocol and service that may be used to control the disposition of the programs and files and the execution of processes on remote hosts, to query their status and to retrieve the results. The X.400 electronic mail system, also known as Message Handling System (MHS) is specified in CCITT X.400-X.440 and in ISO 10021. The system consists of Message Transfer Agents (MTAs), that store and forward messages through the network and User Agents (UAs) that present the mail to the end user and allow him/her to send mail. The X.400 P1 protocol which is used between MTAs is based on the RTSE. The MTAs transfer the messages to and from the UAs using the P3 protocol or by local means (e.g. the file system if both processes run on the same host). The Message Transfer System (MTS) that is formed by all MTAs may be used for Interpersonal Messaging (IPM) or for other purposes (e.g. system management). The MTS is used for sending mail to other people directly or via Distribution Lists (DLs) and to transport delivery reports (after the message has been delivered or discarded) and receipt/non-receipt notifications (after the message has been read by the recipient or deleted without ever having been seen by the recipient) back to the sender. MTAs may be capable of converting message body part types (e.g. different character sets or voice data encodings) and rerouting if default links are unavailable. X.500-X.521 and ISO 9594 specify the OSI Directory Service (DS). The DS is a distributed database used for storing information about people, organizations, application processes (e.g. MTAs or public DFR servers), routing tables, etc. X.500 may be used to search the X.400 addresses of people interactively as well as other attributes like their phone number, postal address, preferred delivery method (fax, mail, etc.), photo and public keys. X.509 specifies a distributed authentication framework based on the DS. The X.500 directory information base is structured hierarchically, i.e. the entries that represent real world objects (countries, persons, servers, management information, news groups, distribution lists, groups of persons, organizational roles, etc.) are connected to a world wide tree. Each entry has a number of standardized or locally defined attributes and a unique Distinguished Name that describes its location in the tree. Generally, there are nodes for countries under the root and nodes for organizations under each country and these may be further subdivided and contain person entries, etc. But also other tree stuctures are possible. Powerful search queries allow the implementation of easy-to-use Directory User Agents (DUAs, the clients) that provide users the ability to find information stored in the interconnected Directory System Agents (DSAs, the servers). The DSAs talk to each other using the Directory System Protocol (DSP). DUAs send their queries and modification commands to the DSAs using the Directory Access Protocol (DAP). The Document Filing and Retrieval (DFR) service and protocol are defined in ISO 10166. A document store may contain a large number of documents (ASCII texts, word processing files, hypertext files, software packages, etc.) together with attributes like title, name of the author, date of creation and latest modification, version number, pointers to other copies of the same document, pointers to older versions, language, summary, keyword list, access rights, lock semaphores and so on. Documents may be arranged in a tree and described with attributes very similar to the X.500 database. DFR allows the implementation of an easy to use distributed information retrieval system similar to the Internet gopher. In addition to the gopher protocol, the DFR protocol provides the ability to store and modify documents, access control, searches on attributes, a version control mechanism and other things. Documents may also be represented by links to other DFR servers and a unique identifier is assigned to each document by the system, so that the user need not be aware that he/she accesses several servers while browsing through the document (and perhaps hypertext) space. Documents may be of various types (e.g. ODA, SGML and HyTime, X.400 IPM messages, binary). The Bibliographic Search, Retrieval and Update Service and Protocol (SR) are defined in ISO 10162/10163. It is based on NISO Z39.50. An Interlibrary Loan Service and Protocol are specified in ISO 10160/10161 for library applications. ISO 10031 defines Distributed Office Applications (DOA). The Manufacturing Message Specification (MMS) Service and Protocol have been defined for controlling and integrating industrial automation systems (ISO 9506). An application layer protocol for Remote Database Access (RDA) is specified in ISO 9579 and a Distributed Transaction Processing Model, Service and Protocol is defined in ISO 10026 and X.850/860/870. This was a very short overview on the application layer. Now let's dive into the deeper layers. The OSI presentation layer service and protocol are defined in ISO 8822/8823 and X.216/226. A connectionless mode protocol version is specified in ISO 9576. The OSI session layer service and protocol are defined in ISO 8326/8327 and CCITT X.215/225. The connectionless variant is specified in ISO 9548. The OSI transport layer service and protocol are defined in ISO 8072/8073 and X.214/224. These standards define 5 different flavors of one transport protocol for the connection-oriented transport service. TP0 is the simplest version, and assumes that the network service is reliable enough for the application. TP1 provides error recovery, i.e., after a network failure, the transport layer implementation is capable of automatically reestablishing the connection without notifying the higher layers. TP1 won't detect errors that are not signaled by the network layer, e.g., by a disconnect message. TP2 provides the ability to multiplex several transport connections over a single network connection and TP3 provides both error recovery and multiplexing (TP1+TP2=TP3). Finally, TP4 provides all this, plus error detection, error correction and packet resequencing. TP4 is intended to be used over unreliable connectionless networks. ISO 8602 defines a protocol for the connectionless transport service (CLTS) and ISO 11570 a transport protocol identification mechanism. The network service, and the secrets of OSI network service access point (NSAP) addresses, are defined in ISO 8348 and X.213. ISO 8648 defines the internal organization of the network layer in 3 sublayers and ISO 8880 describes protocol combinations for the network service. ISO 10028 specifies the relaying function of an intermediate system. The connectionless network service may be provided by the connectionless network protocol (CLNP, also known as ISO IP) defined in ISO 8473. In combination with CLNP, the End System to Intermediate System Routeing Information Exchange Protocol (ESIS) defined in ISO 9542, the Intermediate System to Intermediate System Routeing Information Exchange Protocol (ISIS) defined in ISO 10589 and the Protocol for Exchange of Inter-Domain Routeing Information (ISO 10747) may be used. CLNP is normally used together with TP4 as the transport protocol. The connection-oriented network service (CONS) may be provided by X.25 (ISO 8202) as defined in ISO 8878|X.223. ISO 8881 extends X.25 for use in local area networks, ISO 10732 describes some details of using X.25 for providing the CONS over the telephone network and ISO 10588 describes how to use X.25 over X.21/X.21bis lines for providing the CONS. ISO 10177 defines an intermediate system using X.25/CONS and ISO 10030 is the ESIS version for X.25/CONS. Using ISDN (the new digital telephone network) for providing the CONS is specified in ISO 9574. And another layer: the Data Link Service is defined in ISO 8886|X.212. Most data link layer protocols are based on the High-level Data Link Control (HDLC) family of error correction protocols. These are described in the standards ISO 3309/4335/7478/7809/8471/8885. One popular HDLC protocol is the subset LAPB defined in ISO 7776, which is often used with X.25 on point-to-point lines. ISO 8802 (also known as IEEE 802) defines several LAN systems, e.g. ISO 8802-3 is the well known Ethernet (CSMA/CD) specification. ISO 8802-2 defines the data link layer protocol for LANs Logical Link Control (LLC). LLC1 is the connectionless and LLC2 the connection-oriented version. The Fiber Distributed Data Interface (FDDI) is a fiber optic LAN system for 100 Mbit/s specified in ISO 9314. The Physical Layer Service Definition is defined in ISO 10022|X.211. The physical layers of LANs are, in most cases, defined in the same documents as the layer 2 descriptions. There are also many ISO and IEC standards for all kinds of plugs and connectors. OSI standards define a lot of options, and they may be combined in a huge variety of ways in order to be suitable for all kinds of requirements (and sometimes for political reasons :-( ). Consequently, if you have two boxes that claim to be OSI conforming, this doesn't mean that you can plug them together and they will work together, because they can use different lower layer protocols and different higher layer options. In order to create standards that allow that conforming and compatible products will interoperate, profiles have been defined. A profile is a set of options and combinations selected from the protocol standards such that it is guaranteed that implementations conforming to the (same!) profile will be able to communicate. Technical report ISO TR 10000 gives the ISO profile framework. 'A' profiles have been defined for application layer protocols (e.g. AFT11 in the international standardized profile ISO ISP 10607 for a simple FTAM file transfer subset and AOM12 in ISO ISP 11183 is an enhanced management protocol subset), 'T' profiles define layer 1-4 stacks (ISO ISP 10609) and 'F' profiles are for file formats (e.g. FOD36 is a de luxe version of ODA). A good list of all OSI related standards and their current status is printed twice a year in the ACM SIGCOMM journal Computer Communication Review. A list of CCITT standards is available from the Teledoc mail server described in the standards FAQ where you'll also find a short list of other ISO standards relevant to computing. For more information, order the orange ISO Catalogue from your national ISO member body. How are OSI and TCP/IP related? ------------------------------- TCP/IP is a suite of protocols that has been developed by the US Department of Defense and that are used on the Internet. Software supporting TCP/IP is part of nearly every UNIX distribution today. TCP/IP is not a OSI protocol and does not fit in the OSI reference model. However, the service provided by IP is very similar to the connectionless network service provided by CLNP, and so, IP is generally called a layer 3 protocol. Similarly, TCP may be compared with TP4 and can be seen as a layer 4 protocol in the reference model. The major differences are the address space, which is a 4-byte sequence in IP and up to 20 bytes in OSI, and the fact that TCP is a stream-oriented protocol that doesn't provide any protocol data unit boundaries. Other details are a few missing features in TCP/IP like quality of service negotiation and routing restrictions. The Internet standard RFC 1006 defines a method of providing the connection-oriented transport service (COTS) for OSI over TCP. This is done using a packet length indicator and the TP0 protocol. RFC 1006 is only an interim solution, and there are long term plans to introduce CLNP in the Internet. OSI Services that are used today on the Internet (e.g. the X.400 and X.500 pilots) use RFC 1006 over TCP/IP. The higher layer protocols in the DoD/Internet suite may be mapped as follows: DoD/Internet OSI ---------------------------------------------------------------- ftp FTAM RFC822, SMTP, MIME X.400 Telnet, rlogin VT Gopher+, WWW DFR WAIS SR (both are based on Z39.50) SNMP CMIP USENET, NNTP X.gc X Window System (will be included in OSI) NTP (network time protocol) (under consideration by CCITT) OSPF, ISIS ISIS Internet Protocols with no OSI equivalent today: Relay Chat, IRC OSI has only a standard name for this so far: synchronous group communication Talk might perhaps be defined as a VT profile OSI protocols with no TCP/IP equivalent: X.500 perhaps finger :-) JTM parts of DFR parts of X.gc RDA MMS Interlibrary Loan Protocol Which is better: TCP/IP or OSI? ------------------------------- This question periodically results in flame wars in comp.protocols.iso. If you missed the last one, here is one opinion: Neither. In theory, OSI has the more advanced feature set, including significantly more sophisticated application protocols including some for services not available at all in the TCP/IP suite. In practice, TCP/IP is much more widely implemented and deployed, so you are much more likely to find TCP/IP products to suit your needs, and typically at much lower prices than equivalent OSI products. don provan donp@novell.com [Others are welcome!] OSI criticism ------------- The OSI protocols still suffer from not being used outside communities where their use is enforced by regulations. Many other protocols (e.g. TCP/IP, SNA and Novell) are much more popular than the official standards of computer networking and many people think that the following reasons have contributed to this situation: - OSI protocols haven't been tested widly before having been standardized and are not based on existing practice in large scale computer networking (e.g. Arpanet). - OSI standards are (compared to Internet standards and RFCs) very expensive and difficult to obtain. - The OSI reference model is too complex and has too much layers. The session layer should better be a part of the application layer and isn't of much use at the current position. Although it is possible to implement just a minimal kernel functionality of both the session and presentation layers, even having to understand the very difficult documents isn't very motivating. - Promising new network technologies like ATM networks don't fit in the OSI reference model very well and many important techniques like LANs, RPC and stateless protocols became popular after the OSI RM had been standardized. - Having two completely incompatible alternative protocols (CLNP and X.25) at the network layer (and consequently many different transport layers that try to compensate the differences) isn't what helps you in building up a fully interconnected easy to use and maintain global network. There is broad agreement among knowledgeable people that a connectionless network layer is technically superior to the X.25/TP0 approach (which in practice provides NO reliable end-to-end transport service, because recovery from intermediate node failures is impossible). Christian Huitema <huitema@mitsou.inria.fr> explained the various problems with OSI quite well when he posted suggestions about explaining the design principles behind OSI to students in network classes: "Once the class is reasonably at ease with the "basics", it is relatively easy to introduce the OSI model -- as a baroque left over of the 70's. You have to do it with an historical perspective; a few tips: * the model was invented before local networks, and also before RPC. * the layer decomposition dates back from the time when you had the transport programmed in a "front end" and a "session control" programmed in a "channel manager". * ASN.1 was *NOT* part of the original model. If you go back to the early ideas, there should not have been an "application standard". Rather, the presentation would specify some "common document format", common to all applications. The session would be used to ensure that a "consistent" copy of this common document was kept at both end. * the session itself cannot be understoud if you don't present T.62 -- or rather, 1980's S.62. Why modern applications would have to bear the load of compatibility with a still born super-telex service is indeed a matter of interesting debate. * explaining the relation between an application syntax, a presentation context, an application context, an application entity, an application process and a PSAP address is great fun. * indeed, the use of session through the presentation by ACSE, RTSE and CCR is also amazing. Then you end up the class explaining that all this is not very serious..." Which free OSI implementations are available? --------------------------------------------- ISODE (pronounce it ISO-D-E, but don't call it the ISO Development Environment) implements ISO layers 4-7 on UNIX systems. Among the supported lower layer stacks are RFC1006/TCP/IP and various X.25 and CLNP implementations. With ISODE you get ASN.1 tools and implementations of X.500 (QUIPU) and FTAM. Version 8.0 is the last public domain version and an ISODE Consortium has been founded that will coordinate further development on a commercial basis. A free Patch No. 1 with bug fixes for ISODE 8.0 has been provided by the ISODE Consortium which can be ftped from isode.com. The ISODE and QUIPU mailing list archives are available via anonymous ftp and gopher from info.educom.edu. The isode and quipu are in /pub/isode and /pub/quipu respectively. PP is a X.400 message transfer agent and a gateway to other e-mail systems based on ISODE. The current public domain version is 6.0 and further commercial development will be done by the ISODE Consortium. Both ISODE and PP are available from many anonymous ftp servers, e.g. from cs.ucl.ac.uk in directory src. OSIMIS is UCL's OSI management system. It does not intend to provide a comprehensive set of OSI management facilities but rather to show how the rich OSI Management functionality can be exploited and to provide facilities of a generic OSI management platform. In particular, extended support through an object-oriented (C++) Application Program Interface (API) is provided to implementors of management applications in both agent and manager roles, which hides the details of management information access through the OSI management service/protocol CMIS/P. The system has been developed using ISODE 7.0 and GNU C++ and is available with anonymous ftp from cs.ucl.ac.uk [128.16.5.31] in the directory osimis. [Posted by Peter Kay <P.Kay@massey.ac.nz>:] The clients of ISODE 8.0 have now been ported to OS/2. (pepsy, pepy, posy, rosy, isoc, imisc, ftam, dish, de and sd). They are available by anonymous ftp from cc-vms1.massey.ac.nz (130.123.1.4), in the files os2isode80.zip (for those who want to rebuild the system) or os2isode-runtime.zip (for those who only want the executables). I suggest you copy and read the file os2readme first. The port was based on Essex Systems Inc TCP/2 package. It will NOT work with any others. To run the programs you will need the TCP/2 package. To rebuild the system you will also need its Developers Kit and the Microsoft C v6.0 compiler. [Posted by Graham Wheeler <gram@aim1.aztec.co.za>:] An MS-DOS-based ESTELLE compiler/interpreter should be on simtel, in the Networks directory, with the name PEW2_1.ZIP. New and planned OSI standards ----------------------------- A group is working on an 'asynchronous group communication' standard based on X.400, X.500 and DFR. This will include a news system similar to but more sophisticated than USENET and facilities for joint editing of documents and voting/polling. The name of the draft document is currently X.gc. X.400(1988) has been extended to include voice, Electronic Data Interchange (EDI) and file transfer in the message body. Also many bugs in the specification have been fixed. X.500(1993) has been finished and will define a new replication protocol, extended search methods, access rights, attribute inheritance, ISO 10646 strings and other things. It will be published in late 1993. An addendum 1 (filestore management) to FTAM now defines a hierarchical file system with subdirectories, links, paths, etc. Previously, paths have been long file names and were OS dependent (e.g. / in Unix, \ in MS-DOS) and directories have been treated like files (e.g. '.'). HDLC has been extended to include an asynchronous mode that defines how to use the layer 2 framing with start/stop bits and byte stuffing on the serial ports that are part of every PC. Check ISO 3309 addendum 1-3. ISO is working on an OSI-based remote procedure call standard (ISO CD 11578). A new version of ASN.1 is about to be released. The new ASN.1 standard consists of a 4-part document: ITU-T Rec. X.680 | ISO/IEC 8824-1 ITU-T Rec. X.681 | ISO/IEC 8824-2 ITU-T Rec. X.682 | ISO/IEC 8824-3 ITU-T Rec. X.683 | ISO/IEC 8824-4 The first part is very similar to 1990 ASN.1, except that there is no more macro notation or ANY DEFINED BY. Also, there are niceties such as automatic tagging and support for multi-byte characters in the new ASN.1. The last 3 parts replace the macro notation and ANY DEFINED BY. On the encoding rules side there is: ITU-T Rec. X.690 | ISO/IEC 8825-1 ITU-T Rec. X.691 | ISO/IEC 8825-2 The first contains the good old Basic Encoding Rules (with support for multi-byte characters, etc.), plus the Canonical Encoding Rules and the Distinguished Encoding Rules. The second is the Packed Encoding Rules. Books and Journals ------------------ [Posted by Even Splett <e_splett@trofs.enet.dec.com> and others with comments collected by Khac Binh Su <kbs@ccr-p6.ccr.jussieu.fr> and others:] Data communications, Computer Networks and OSI Halsall, Fred 549 p. Addison-Wesley ISBN 0-201-18244-0 Networking in Open Systems; international seminar, Oberlech, Austria, Muller, Gunter. Blanc, Robert P. Berlin, Springer-Verlag, c1987 Lecture notes in computer science; 248 441 p. QA76.L42 v.248 1987 ISBN 3540177078 OSI Explained; end-to-end computer communication standards. Henshall, John, Shaw, Sandy. Ellis Horwood Ltd. distributed by John Wiley & Sons Ltd. 217 p. TK5105.5.H47 ISBN 0745802532 Ellis Horwood ISBN 0470211008 Halsted Press Very good on transport and above, including a consolidation by 3 examples that shows how the upper layers work together to establish an association, transfer data, and release it. It also has a chapter each on FTAM, X.400, and X.500, but does very little with ASN.1, a real weakness in an otherwise excellent book. Its other virtue: it is under 250 pages. Open Systems; the Basic Guide to OSI and its Implementation. Judge, Peter J. QED Information Sciences Authorized reprint of -- Sutton, Surrey, Computer Weekly. (ISBN 1853840092) 184 p. TK5105.5.J83 1989 ISBN 0894353101 Open Systems Karial, Henry S. JA71.K32 1969 OSI: a Model for Computer Communications Standards Black, Uyless D. Prentice Hall TK5105.5.B5656 1991 ISBN 0-13-637133-7 An excellent OSI introduction. The Open Book : A Practical Perspective on OSI Rose, Marshall T Tk5105.5.R67 1989 Prentice Hall ISBN 0-13-643016-3 It is fun reading, and it gives you the general idea about the whole stuff. One of its most interesting topics is transition: how to migrate to OSI from a TCP/IP oriented world. Excellent, but not cheap. In Germany it is 150,-- DM. I started with Marshall T. Rose's The Open Book - a practical perspective on OSI by Prentice-Hall. It came out in 1991 so it is quite up to date, but not cheap (at least in Finland). It is not an exclusive book on the upper layers of the OSI. Nevertheless, his presentation of the upper layers in a couple of chapters is sufficient enough to start. I am not such a fan of Marshall Rose's "The Open Book" as I once was. At this point, the book is getting a bit dated (the publication date is 1990 on my edition; a lot has changed in that time), and it emphasizes the upper layers to the detriment of the lower layers. I have found the book by Uyless Black superior in several respects: it is newer, it is technically denser, and it refrains from excessive editorializing. Complete guide to ISO protocols Vol 1 Thomas, Steve Springer Verlag ISBN 0387970231 Handbook of computer communications standards, Vol 1 The Open Systems Interconnection (OSI) model Stallings, William 1989 ISBN 0-672-22664-2 Howard W. Sams & Company ISBN 002948071x Macmillan This book is OK, but lacks the finer details. An introduction to Open Systems Interconnection MacKinnon, Dennis 254 p. Computer Science Press 1990 TK 5105 M3335 1990 ISBN 0716781808 Standards for Open Systems Interconnection Knowles Blackwell Scientific Publications ISBN 0632018682 OSI in Microcomputer LANs Strom, Jim. 125 p. Manchester: NCC Publications, 1989. TK 5105.5 S87 1989 ISBN 0850127114 (pbk) ASN.1, The Tutorial and Reference Douglas Steedman Technology Appraisals, 82 Hampton Road, Twickenham, TW2 5QS, U.K. (Fax +44 81 744 1149) ISBN 1 871802 06 7 Open Systems Interconnection by Gary Dickson and Alan Lloyd Prentice Hall Australia (1992) ISBN 0 13 640111 2 ISODE 8.0 Manual The ISODE manual is a nice reference material if you are looking for implementation details of the upper layers. In fact, looking at ISODE code is probably the best way to see how the "theoretical" stuff is applied. Teleinformatique by Nussbaumer, published by Presses polytechniques romandes (french version) The vol 3&4 are the best books available in french for the upper layers. Computer Networks by Andrew Tannenbaum This book explains accurately the general aspects of problems up-to layer 6. Layer 7's description is a bit vague. A very nice introduction in computer communication that also covers OSI. Highly recommended for computer science students and others searching a good general networking introduction. Communication Network Protocols - OSI Explained Brian W. Marsden Chartwell-Bratt (UK) 1991 (3rd edition) ISBN 0-86238-276-9 It is extremely idiosyncratic, and should not be read except in conjunction with another book. Also, only some of it is about OSI. It is, however (a) very cheap (15 UK pounds), and (b) the only book I know of which talks about the UK Coloured Book protocols. These had a major impact on some parts of OSI, particularly JTM, as well as being interesting in their own right. Networking Standards A Guide to OSI, ISDN, LAN, and MAN Standards Stallings, William Addison-Wesley 1993 627 pages ISBN 0-201-56357-6 Provides an overview of basic OSI standards, then a detailed technical discussion of leading-edge OSI-related standards, including internetworking and routing, ISDN and BISDN, LAN and MAN, network management, security, and international standardized profiles. [End of comp.protocols.iso FAQ] -- Markus Kuhn, Computer Science student ½░o░╗ University of Erlangen, Germany Internet: mskuhn@cip.informatik.uni-erlangen.de | X.500 entry available